How to: Configure an activity to use transaction aggregation
Transaction aggregation streamlines the process of banking and transaction processing, removing repetition, minimising paper and centralising responsibility. If your
practice adopts this methodology, it will be necessary to set up
workflows for the relevant
transaction activities to utilise aggregation. Without these provisions, transaction activities will progress normally through the
request-authorise-process workflow.
Step 1: Limit payment methods
The first step in creating a transaction activity that uses aggregation is to limit the payment methods to include only those affected by the aggregation. This will vary according to the type of aggregation being performed. You do not have to include all possible payment methods, only those you want to aggregate.
Create a new activity and select your desired type of transaction.
Add the payment methods you want to aggregate.
Step 2: Create a workflow
Move to the 'Workflow' tab on the activity editor and add the appropriate number of steps - for most types of receipts, a 2-step workflow is sufficient. For most types of payments, a 3-step workflow is appropriate.
For a 2-step workflow, set the action on the first step to 'Authorise'. For a 3-step workflow, set the action on the first two steps to 'Request' and 'Authorise'. (Allowing authorised members to skip the first step in a 3-step workflow is highly desirable.)
Step 3: Configure aggregation
On the final step in the workflow, set the action to 'Create a mutually exclusive task'. In the field below, select the appropriate aggregation activity. This workflow action will create a task for the aggregation activity, ensures that there is only ever one such task in the system at any point in time.
Step 4: Apply appropriate permissions
Assign
permissions for the new activity. Logically, any
member who has permission to perform the second-to-last step of the workflow must also be granted permission to perform the final step. (If you do not assign permission, the system will create a task solely to create the aggregation task itself.)
A number of internal rules within the system make this configuration behave as expected:
- Transactions cannot be advanced further than the state they were in when their workflow completed (except through aggregation). This ensures that no member can process an aggregatable transaction separately.
- Mutually exclusive tasks cannot be delegated to a specific member, and there may be only one in existence at any time. This prevents extraneous aggregation tasks from being sent.
- Since the transaction activity supports only the necessary payment methods, conventional (unaggregated) rules can still be applied to the other payment methods.
- Aggregation activities only support a subset of the available payment methods. The system will never suggest aggregating transactions that cannot logically be grouped.